iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 30
0
總覽

API 路徑(Endpoint)的一般安全準則。

注意事項
  • 存取控制
    API路徑應遵循最小特權原則。具有受保護訊息的服務應服務於最小的群體。
    具有錯誤配置的存取控制的API可能導致意外的訊息洩漏,或對敏感資料進行未經授權的惡意更改狀態的操作。
    • 問題範例:
      POST,允許用戶修改帳戶訊息,而無需檢查用戶是否擁有要修改的帳戶。
      一個GET請求,該請求無需身份驗證即可返回敏感的訊息性訊息。
    • 修正方式
      確定哪些API操作應被視為敏感或公開的。
      • 對於內部API:盡可能限制網路存取。
        理想情況下,這些路徑應被限制在一個封閉的網路中。
        並且要求比單一API金鑰更強的身份驗證。
        例如,多因子身份驗證。
      • 對於具有敏感訊息的公開API:
        在執行請求的任何操作之前,需要進行身份驗證。
        API金鑰應該是可撤銷的,也可以是可更新的。
      • 對於提供公開訊息的公開API:
        確保未通過身份驗證未通過公開API執行任何狀態更改操作。
        考慮速率限制,以防止單個主機在短時間內發出太多請求。
    • 風險等級
      根據情況從低到高不等。
    • 參考資料
      https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
  • 輸入驗證
    傳入的資料在解析時可能格式錯誤或被設計為導致意外行為。
    根據輸入的解析方式,未驗證的輸入可能包含命令注入或其他有害操作。
    • 修正方式
      • 類型檢查:
        確保輸入為預期的資料類型,拒絕其他任何內容。
        確保輸入為預期的資料類型,拒絕其他任何內容。
      • 長度和大小檢查:
        輸入應在預期的長度或大小之內。
        拒絕任何大於或小於預期的內容。
      • 將白名單接受的內容類型
      • 限制http方法
    • 風險等級
      根據情況從低到高不等。
  • 驗證要求
    有可能在原始請求者和API路徑之間的傳輸過程中修改請求。
    修改後的請求可能導致對原始請求者的資料進行狀態更改操作。
    或者導致要提供的資料不正確,修改或意外。
  • 重播攻擊
    攻擊者發送了先前的真實請求,以使操作在以後的時間再次發生。
    傳輸中已修改的請求:攻擊者會在發送真實請求時修改資料。
  • 通用安全實踐
    即使遵循API的最佳安全做法,也有可能錯過其他惡意活動。
    • 問題範例:
      沒有日誌記錄或監視丟失的安全事件
      返回服務後端的堆疊紀錄或其他描述性訊息
    • 修正方式
      • 記錄並監視API活動。
        檢測異常可以幫助發現其他地方沒有發現的惡意活動。
      • 禁用CORS(跨源資源共享)
        或者將CORS的範圍縮小到最小,以防止偽造的請求或資料洩漏。
      • 返回模糊的錯誤回應。
        向用戶返回錯誤時,請盡可能少地提供訊息。
        不要返回有關服務器環境的任何訊息或調試訊息,例如堆疊紀錄。
    • 風險等級
      根據情況從低到高不等。

上一篇
Ruby 最佳實踐
下一篇
授權和認證開發方法
系列文
安全軟體開發生命週期(SSDLC)學習筆記36
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言